Generally, when executing software that requires different safety integrity levels, measures need to be put in place to reduce a risk of interference. Typically, issues of interference arise when one safety critical task interferes with a second safety critical task, causing potentially dangerous malfunctions to software-based processes due to reduced processing performance resulting in a reduced progressing progress of at least one of the safety critical tasks.
Worst case execution time (WCET) is typically used for understanding timing behaviour of software where it is important for reliability or correcting functional behaviour. Calculating WCET generally involves generating approximations, which usually includes overestimation when there are uncertainties. Therefore, in practice the exact WCET itself is often regarded as unobtainable. For modern systems, utilising WCET can require a huge effort and can lead to inefficient implementations due to the involved approximations and worst case assumptions.
Targeting performance domain interference of software executed either in a time sharing manner by a single computing shell or on different computing shells integrated in a multiprocessor system, requires quantifying disturbances that are due to interferences in the performance domain. Interferences can occur due to sharing of state based resources, for example, having bi-stable elements or concurrent access to shared resources.
Current methods generally measure a time duration that a specific software task requires for execution. Unfortunately, state of the art processing shells are less and less deterministic in the time domain, and execution time relies heavily on executed instructions, the processed data, and the process circumstances. Therefore, as a result, time windows for time domain performance monitoring have to be ever wider and wider.
SnoopP is an on-chip, functional level, non-intrusive profiler for software applications running on soft-core processors. SnoopP comprises a user-specified variable number of segment counters that are used to measure a number of clock cycles spent in executing contiguous regions of memory. Each segment contains two comparators to check a value of the program counter between a specified low and high address. If the value of the program counter is presently accessing an address within these bounds, then the counter value is incremented. A counter clocked by a central processing unit (CPU) clock and masked by logic, is utilised to validate if a CPU program counter is within a given range. This enables the counter to assess the CPU time spend within the user specified address space.
In general, this is used for profiling purposes, to identify the code section that processing elements spend most of the CPU time. However, it is known that this approach is sensitive to non-deterministic behaviour (e.g. data dependent execution time) and, therefore, provides only a limited diagnostic coverage. As this approach only accumulates the total CPU time spend to process the instructions within a given instruction address range, it is prone to all types of non-determinism of computer processing. This approach does not differentiate the CPU time spend for example on only fetching data, fetching instructions, processing interrupts, CPU stall cycles, number of instructions completed, number of memory accesses (by type), number of instruction or data cache misses, number of cycles with multiple instructions issue, number of instructions in a given class completed (load/store instructions, branch/subroutine/return instructions, integer, floating point instructions, etc.), cache line fills, and calling subroutines, As these different CPU times are differently influenced by software interferences or hardware non-determinism this approach does not allow to tailor the CPU timeout window to the specific indicators of a software interference.
In summary, performance interference reduces the performance of a processing unit whilst processing a safety critical software task due to interference of a second software task having a different safety criticality. Current methods of performance interference monitoring are only generally handled by imprecise time-based measurements.
Current methods generally measure a time duration a specific software task requires to complete its execution (so called timeout watchdog or window watchdog). Unfortunately, state of the art processing shells are becoming less and less deterministic in the time domain. A reason for the reduction of execution time determinism may be due to more and more speculative operations performed within a core. In the case that these speculations are correct, the results are available earlier. However, in the case that these speculations are incorrect, the same instruction will take longer to process.
Further, the hierarchical memory system (cache) may also attempt to speculatively pre-fetch and store data and instructions. In the case that the speculative fetches were correctly predicted, execution time will be fast. However, performance may be significantly slowed down if the predicted behaviour did not correspond to the program behaviour.
The execution time relies heavily on the executed instructions, processed data and the number of context switches (interrupts) etc. As a result, the time windows for time domain performance monitoring have to be wider and wider.